home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 13935 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.0 KB  |  94 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.uunet.ca!wildcan!sq!msb
  3. From: msb@sq.com (Mark Brader)
  4. Subject: Re: problem: sun4 and hpux char * difference
  5. Message-ID: <1996Apr10.231505.27218@sq.com>
  6. Summary: Undefined behavior; null pointers are not null strings
  7. Organization: SoftQuad Inc., Toronto, Canada
  8. References: <Dpnpn5.Lo3@Cadence.COM>
  9. Date: Wed, 10 Apr 1996 23:15:05 GMT
  10.  
  11. [Posted and emailed.]
  12.  
  13. Timothy McCoy (tmccoy@nntp.cadence.com) writes:
  14. > I have a program that is made for hpux and sun4 users.
  15. > The sun program fails and the hpux version does not.
  16.  
  17. The program's behavior varies because it is undefined.  If undefined
  18. behavior is a difficult concept for you, please reread the discussion
  19. of it in the FAQ list, particularly the last few questions in Section 11.
  20.  
  21. > I believe I understand why its dieing on the sun, as 
  22. > a null (zero) address can't ...
  23.  
  24. Whoa there.  Just a moment for a side issue.  A null pointer is not
  25. necessarily represented as a zero address, and hence initializing a
  26. char * value by calloc()ing the variable does not necessarily yield a
  27. null pointer.  It happens to yield one on common implementations, but
  28. you can't assume it always will.  Please reread the discussion of null
  29. pointers in Section 5 of the FAQ list.  If you have a malloc()ed or
  30. calloc()ed structure and you want to set one of its members to be a
  31. null pointer, you should do it explicitly:
  32.  
  33.     lrec->node_name = NULL;
  34.  
  35. > ...a null (zero) address can't be read from (really) but
  36. > myself and others thought that it was 'standard' to 
  37. > interpret it as zero and (in this example) copy '\0'
  38. > into astring, which is just what the hp does.  
  39.  
  40. "Yourself and others" are mistaken.  The behavior when you indirect
  41. through a null pointer is undefined.  Some implementations happen
  42. to behave in the way you described, making a null pointer look like
  43. a legitimate pointer to a null string; but unless the program is
  44. intended to run only on such implementations, it has a bug (as you
  45. found out).  Null strings and null pointers simply are two different
  46. things, as mentioned in question 5.13.
  47.  
  48. > Additionally, why, Why, WHY does the sun version of this:
  49. >    printf("name='%s'\n", lrec->node_name);
  50. > yield this:
  51. >    name='(null)'
  52.  
  53. This feature is provided precisely for the purpose of making it easier
  54. for you to find and eliminate this bug.  If it printed name='', then you
  55. might easily think that you *really had* a null string, and go off looking
  56. for some other reason why the program was aborting.
  57.  
  58.  
  59. > P.S.  I resolved a small portion of the problem witha declaration:
  60. > char *CNULL = { "\0" };
  61. > ...
  62. > lrec->node_name = CNULL;
  63.  
  64. That's one way to fix the code.  Most people would eliminate the variable
  65. CNULL, though.  The only significant reason to use it is if you need all
  66. the node_names that are null strings to also be equal when compared as
  67. pointers.  If you don't need that, then you can just write:
  68.  
  69.     lrec->node_name = "";
  70.  
  71. (You get a \0 for free at the end of a string literal, so you don't need
  72. to supply an extra one.)  Two node_names separately initialized to ""
  73. may or may not compare equal as pointers, depending on the implementation.
  74. (If they are initialized from the same "" literal, they will.)
  75.  
  76.  
  77. An alternative fix is to let the node_name be a null pointer when there
  78. is no node_name, and fix the code that dereferences it, by testing whether
  79. lrec->node_name is a null pointer at the appropriate times.  This way
  80. probably produces cleaner code in more cases than using null strings.
  81.  
  82.  
  83. -- 
  84. Mark Brader, msb@sq.com, SoftQuad Inc., Toronto
  85.         The precedence don't enter into it -- it's stone undefined.
  86.         This expression makes no sense.  It has ceased to be.  It's
  87.         expired and gone, though sadly not forgotten.  This is a latent
  88.         expression.  Bereft of meaning, it should rest in peace.  If
  89.         people didn't keep nailing it into these discussions, it would be
  90.         pushing up the daisies.  It's rung down the curtain and joined
  91.         the choir ineffable.  This is not an ex-pression.
  92.                 -- Steve Summit (after Monty Python)
  93. My text in this article is in the public domain.
  94.